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1  Introduction 

The  RLF  is  a  knowledge-based  system,  developed  by  Paraniax  with  support  by  the  STARS 
program,  whose  primary  application  has  been  the  design,  implementation,  and  deployment 
of  domain-specific  reuse  library  systems.  A  reuse  library  supports  software  engineers  by 
enabling  them  to  quickly  locate  software  assets  (e.g.  requirements,  designs,  code  modules, 
test  plans  etc.)  that  can  be  of  use  in  their  construction  of  a  software  system. 

- 

What  is  the  RLF? 

•  RLF  stands  for  Reuse  Library  Framework. 

Slide  1  •  Th0  RLp  jg  a  system,  written  in  Ada,  that  enables  the 

creation  of  knowledge-based  systems. 

•  In  particular,  the  RLF  has  been  applied  to  the 
creation  of  domain-specific  reuse  libraries. 

-  ^ 


A  domain  is  an  application  area,  typically  the  one  of  immediate  relevance  to  the  software  en¬ 
gineer,  and  a  domain  model  is  a  machine  representation  of  information  about  the  application- 
area  and  the  library  assets  available  for  the  application  area.  The  model  can  contain  general 
domain  information  along  with  data  about  the  form,  fit,  and  function  of  the  available  library 
assets. 

This  is  an  initial  version  of  an  RLF  administration  training  package.  This  package  comple¬ 
ments  training  packages  that  cover  RLF  modeling  and  general  RLF  usage.  The  purpose  of 
this  package  is  to  provide  an  orientation  for  new  RLF  administrators  -  those  who  are  respon¬ 
sible  for  setting  up  and  maintaining  an  RLF  library.  This  package  assumes  that  its  audience 
is  already  familiar  with  the  RLF  from  an  end-users  perspective,  but  it  does  not  assume  that 
its  audience  is  familiar  with  RLF  modeling  concepts.  In  particular,  having  taken  the  RLF 
Modeler’s  tutorial  is  not  required. 

However,  the  audience  is  expected  to  have  a  general  understanding  of  the  UNIX  operat¬ 
ing  system  and  the  X  Window  System.  If  X  Window  System  experience  is  lacking,  the 
prospective  RLF  administrator  should  identify  a  local  source  of  expertise  in  this  area. 

This  orientation  follows  the  organization  of  the  RLF  Adminstrator’s  manual  which  is  part 
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of  the  RLF  v4.1  release.  However,  the  tutorial  does  not  fully  rover  all  of  the  topics  in  the 
manual.  Nor  does  it  cover  RLF  installation  -  these  topics  are  carefully  presented  in  the  RLF 

Source  Code  Release  Installation  Guide  and  the  RLF  Binary  Release  Installation 
Guide. 

The  orientation  follows  the  following  general  outline. 


The  material  in  this  orientation  supports  a  portion  of  a  domain-specific,  reuse-based,  process- 
driven  approach  to  system  engineering  that  is  the  cornerstone  of  the  STARS  program.  This 
approach  is  embodied  in  the  STARS  Conceptual  Framework  for  Reuse  Processes  (CFRP) 
shown  on  SLIDE  3. 
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In  particular,  the  RLF  supports  the  creation  of  a  reuse  support  structure  and  the  use  and 
management  of  assets  stored  within  this  system.  An  RLF  library  manager  is  most  likely 
concerned  with  the  management  of  assets  that  are  modeled  and  stored  within  a  library 
structure  along  with  managing  the  library  itself. 

SLIDE  4  breaks  out  the  Manage  activity  on  the  CFRP.  A  well-developed  and  presented  RLF 
model  helps  the  maiager  accomplish  all  of  the  tasks  shown  on  the  slide. 


Slide  4 
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2  RLF  Configuration 

The  RLF  installation  guides  are  important  resources  for  the  library  administrator  and  should 
be  consulted  to  learn  the  mechanics  of  installing  and  configuring  an  RLF  library  system.  The 
details  presented  in  the  guides  are  not  repeated  here  and  because  of  the  largely  automated 
installation  process,  the  administrator  should  experience  little  difficulty  in  creating  an  RLF 
installation  for  the  first  time  or  updating  a  prior  installation  with  a  new  release. 

A  successful  installation  should  provide  the  RLF  user  with  five  distinct  applications  along 
with  a  set  of  RLF  sample  libraries.  SLIDE  5  lists  the  basic  applications. 


Slides 


The  installation  guide  tells  how  to  verify  if  these  applications  have  been  installed  correctly. 
The  rest  of  this  orientation  assumes  that  installation  has  been  successfully  completed.  The 
administrator  should  test  the  installation  of  the  applications  by  executing  them  using  the 
sample  model  and  library  data  provided  in  the  installation. 

General  RLF  usage  and  administration  can  be  simplified  by  creating  an  RLF  execution 
environment  through  the  use  of  RLF-specific  UNIX  environment  variables.  The  role  of  these 
variables  is  summarized  on  the  next  slide. 
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RLF  Environment  Variables 

RLF.LIBRARIES  --  UNIX  path  where  RLF  library  data  is  located 

RLP-WORKING-DIR  -  UNIX  path  which  RLF  should  use  for 
user  and  OS  actions  (e.g.  asset  extraction) 

RLF.EDITOR  --  the  name  of  a  UNIX  program  that  is  invoked 
when  RLF  text-editing  actions  are  invoked 

RLP.PAGER  -  the  name  of  a  UNIX  program  that  is  invoked  when 
textual  library  assets  are  inspected 

XAPPLRESDIR  -  UNIX  path  where  X  resources  are  located  that 
determine  the  layout  of  the  Graphical  browser 

_ 


The  RLF  applications  make  selective  use  of  these  variables,  with  the  Graphical-Browser 
affected  by  all  five  of  them  and  the  Library-Manager  affected  by  all  except  XAPPLRESDIR. 
LMDL  and  RBDL  are  only  affected  by  the  RLF_LIBRARIES  variable.  The  administrator  can  make 
RLF  usage  more  convenient  by  setting  these  variables  for  the  user  in  a  startup  script.  For 
example,  assuming  that  the  RLF  has  been  installed  at  the  top  of  a  UNIX  file  system  named 
/libraries,  the  next  slide  defines  an  appropriate  start-up  script. 


Slide  7 


( - \ 

Start-up  Script  for 
Graphical  .Browser 

#!  /bln/csh  -£ 

setenv  RLF.LIBRARIES  /llbrarles/lnstancee 
setenv  XAPPLRESDIR  /llbrarl«e/rl£/bln 
setenv  RLF.NORKIMO.DIR  /home/ jobndoe 
Or ephlcel.Bro^  ser 

V 


In  addition,  a  library  user  can  personally  tailor  her  usage  of  the  RLF  through  the  use  of  the 


Page  5 


February  1993  STARS-l’C-O^l  r)ti/U19/Ull 

.rlfrc  file.  The  RLF  administrator  should  heroine  familiar  witli  the  .syiita.x  and  features 
of  the  .rlfrc  file  so  that  several  RLF  u.ser  profiles  ran  be  made  available  to  serve  tlie  loral 
needs  of  new  RLF  users.  The  .rlfrc  file  is  presented  in  some  detail  later  in  this  tutorial. 

Along  with  configuring  the  RLF  executables,  the  administrator  needs  to  establish  access 
rights  at  various  levels.  For  the  executables  themselves,  the  (LNTX  file  permissions  atul 
executable  placement  within  the  local  file  system  are  used  to  determine  accessibility.  Kxcei)t 
for  the  GraphicalJBrowser,  access  to  the  RLF  executables  should  be  restricted  to  an  explicitly' 
determined  number  of  users,  typically  the  RLF  administrator  and  designated  RLh"  model 
developers. 

Other  finer-grained  access  restrictions  to  RLF  objects  and  actions  that  can  be  applied  to 
objects  are  handled  by  the  RLF  action  mechanism.  In  particular,  actions  can  be  declared 
as  “privileged”  and  therefore  only  available  through  the  LibraryJIanager  application  (such 
as  editing  the  contents  of  an  asset)  which  is  itself  controlled  through  UNIX  access  controls. 
If  access  to  RLF  library  objects  are  to  be  restricted,  suitable  actions  can  be  installed  in  the 
RLF  library  action  suL  .uodel  to  provide  the  necessary  restrictions.  These  capabilities  are 
discussed  further  later  in  this  orientation.  The  next  two  slides  summarize  access  control 
issues. 


- 

RLF  Access  Control  Issues 

•  Access  to  RLF  Applications 

Only  the  Graphical  .Browser  should  be  freely 
executable 

•  Access  to  RLF  Actions 

Certain  RLF  actions  which  are  declared  pr/V/teped  are 
available  only  from  Library Jfamager  Application 

•  Access  to  RLF  Asset  Objects 

Access  controls  on  library  objects  are  provided  through 
appropriate  actions  within  RLF  library  model 

\ _  ^ 


Since  library  objects  and  UNIX  executables  used  in  RLF  actions  are  themselves  UNIX  file 
entities,  the  proper  UNIX  permissions  must  be  set  for  the  RLF  user  to  access  them.  Failure 
to  do  so  can  result  in  anomalous  behavior  as  experienced  by  the  RLF  user.  For  this  reason, 
the  administrator  should  take  care  in  checking  these  aspects  of  an  RLF  model  installation. 
Another  potential  troublespot  can  occur  if  the  UNIX  tools  that  are  invoked  as  part  of  RLF 
actions  are  not  available  to  the  user  (usually  because  the  user’s  UNIX  path  does  not  include 
the  locations  where  these  tools  reside).  The  action  call  will  report  a  failure  message  -  these 
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messages  can  be  disconcerting  to  new  users  and  should  generally  be  avoided. 


3  RLF  fundamentals 

This  administrator’s  orientation  does  not  go  Into  detail  regarding  RLF  domain  modeling  ca¬ 
pabilities.  These  are  covered  in  the  Modeler’s  orientation  and  in  the  RLF  Modeler’s  manual. 
Howe'  er,  the  administrator  should  have  a  reading  knowledge  of  RLF  model  specifications 
and  be  able  to  edit  them  to  account  for  user-reported  problems  and  model  update  requests 
from  RLF  model  developers.  Some  of  the  basic  slides  in  the  RLF  User  Tutorial  are  reused 
here  to  provide  some  higher  level  context  as  needed. 

An  RLF  library  model  is  a  knowledge  network  describing  an  application  domain.  The  first 
step  in  creating  such  a  model  is  to  identify  the  area  common  to  all  the  assets  to  be  available 
in  the  domain-specific  reuse  library.  A  domain-specific  approach  is  summarized  on  SLIDE  9. 


Slide  9 


RLF  model  specifications  are  made  using  the  Library  Model  Definition  Language  (LMDL). 
A  summary  of  LMDL  features  and  syntax  is  given  in  the  next  few  slides. 


/ - \ 

Domain  Model  approach 

e  Domain  is  an  application  area 

•  Domain  Analysis  produces  knowledge  about  Domain 

•  Encoding  knowledge  leads  to  Domain  Model 

•  RLF  knowledge-base  capabilities  used  to  represent 
model 

•  Knowledge-Based  approach  leads  to  improved  user 
effectiveness 
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Basic  Lmdl  Components 


Slide  10 


•  Categories 

•  Objects 

•  Relationships 

•  Attributes 

•  Actions 


✓ 


SLIDE  11  summarizes  the  important  features  of  model  categories. 


f  Categories 


Slide  11 


•  general  descriptions  of  a  kind  of  thing 

•  classify  what  a  thing  is 

•  arranged  in  an  inheritance  hierarchy  called  a 
specialization  hierarchy 

•  relationships  inherited  along  specialization  hierarchy 

•  most  general  category  occurs  at  root  of  the  model 


An  LMDL  category  definition  defines  a  domain  model  cl«iss  which  stands  for  a  concept  or 
kind  of  thing  that  is  of  potential  interest  to  a  user  of  the  model.  For  example,  SLIDE  12 
shows  some  high  level  category  declarations  for  a  model  of  the  domain  of  sorting. 


Page  8 


February  1993 


STARS-l’C-05ir)(i/019/00 


Slide  12 


- 

Lmdl  Category  Declarations 

root  category  Thing  Is 
end  root  category; 

category  Algorithms  (Thing)  is 
end  category; 

category  "Search  Algorithms"  (Algorithms)  is 
end  category 


SLIDE  12  shows  that  categories  are  declared  hierarchically  where  each  category  names  its 
parents  -  note  that  the  RLF  supports  a  network  model  structure  since  a  category  can  be 
declared  to  have  multiple  parents  (not  shown  in  the  simple  example).  Every  model  must 
declare  a  root  category  which  is  an  implicit  ancestor  of  all  classes  in  the  model. 

Library  elements  are  called  objects  and  must  be  defined  in  terms  of  a  parent  category. 
Objects  are  all  members  of  categories  and  are  distinguished  by  the  relationships  they  have 
as  a  result  of  their  location  in  the  specialization  hierarchy.  SLIDE  13  summarizes  some  key 
properties  of  objects. 
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Slide  13 


- 

Objects 

•  actual  things  instead  of  classifications  of  things 

•  associated  with  the  most  appropriate  category  (or  categories) 
which  describe  them 

•  reusable  assets  are  objects  which  are  identified  through 
attributes  as  well  as  category  relationships  which  are 
“instantiated"  for  the  asset 

•  objects  are  said  to  “individuate”  the  containing  category 


The  next  slide  shows  some  simple  LMDL  object  definitions. 

/ - 


Slide  14 


Lmdl  Object  Declarations 

object  Ada  ("source  lianguage")  Is 
end  object 

object  "Bxanple  Quicksort*  (Quicksort)  Is 
end  object 


✓ 


Categories  and  objects  are  distinguished  primarily  through  the  relationships  and  attributes 
which  they  possess.  SLIDE  15  describes  some  basic  properties  of  relationships  in  the  RLF. 
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Slide  IS 


- ^ 

Relationships 

•  describe  features  of  categories  and  objects 

•  express  associations  between  different  categories  or  objects 

•  are  inherited  by  categories  or  objects  below  that  category  in  the 
hierarchy  at  which  they  are  defined 

•  have  a  name,  an  owner,  a  type  and  a  cardinality 

•  can  be  restricted  by  type  or  by  cardinality  when  inherited  (but  never 
generalized) 

•  object  relationships  “fill”  corresponding  relationships  defined 
between  corresponding  categories 


The  most  important  aspect  of  RLF  models  is  that  categories  can  be  declared  to  have  relation¬ 
ships  (to  other  categories)  and  that  these  relationships  are  then  inherited  by  subcategories  of 
a  category.  In  turn,  objects  which  are  members  of  a  class  can  then  have  particular  instances 
of  these  relationships  attached  to  them.  Relationships  are  defined  in  terms  of  the  “owning” 
class,  the  relationship  “type”  which  is  the  name  of  another  model  class,  and  a  “cardinality” 
which  declares  how  many  repetitions  of  the  relationship  a  particular  object  may  have.  The 
LMDL  specification  given  on  the  next  slide  provides  an  example  of  the  declaration  of  a  set 
of  category  relationships. 
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Lmdl  Relationships 

category  Algorlthna  (  Thing  )  is 
relationships 

ls_wrltten_ln  (0  ..  Infinity) 
of  'Source  Language'; 
works_on  (0  ..  infinity) 

of  'Data  Structure'; 

haa_best_ca8e_of  (0  ..  1)  of  Performance; 
haa_avg_eaae_of  (0  ..  1)  of  Performance; 
has_worat_ca8e_of  (0  ..  1)  of  Performance; 
ha8_slze_of  (0  ..  1)  of  'Lines  of  Code'; 
end  relationships; 
end  category; 

category  'quick  sort'  (  exchange_sorts  )  Is 
restricted  relationships 

haa_best_case_of  (1  ..  1)  of  Logarithmic; 
haa_avg_caae_of  (1  ..  1)  of  Logarithmic; 
ha8_worst_ease_of  (1  ..  1)  of  Quadratic; 
end  restricted; 
end  category; 


As  relationships  are  inherited,  they  can  be  restricted  by  type  and  cardinality  at  a  particular 
subcategory.  A  simple  example  of  this  kind  of  restriction  is  shown  in  the  previous  slide.  These 
restrictions  are  also  permitted  for  objects  and,  in  addition  relationships  can  be  instantiated 
(sometimes  called  “filled”)  which  means  a  link  is  established  between  an  object  in  the  owning 
category  with  a  corresponding  one  in  the  type  category.  The  destination  object  is  said  to  “fill” 
or  satisfy  the  relationship  that  was  originally  defined  between  the  two  cleisses.  For  example, 
the  next  slide  shows  some  role  restrictions  and  subsequent  instantiation  for  particular  objects. 
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Lmdl  Relationships  cont.)  I 

object  exesqple_qulcksort  {  "(lulclc  sort*  )  is 
restricted  relationships 
l8_wrltten_ln  (1  ..  1) 

of  'Source  Language*; 
works_on  (1  ..  1)  of  'Data  Structure'; 
has_worat_caae_of  (1  ..  1)  of  Quadratic; 
haa_slze_of  (0  ..  1)  of  Number; 
end  restricted; 
fillers 

Ada  satisfies  ls_wrltten_ln; 

Array  satisfies  works_on; 

'H'2*  satisfies  has_worst_ca8e_of ; 

'Twenty-Four*  satisfies  has_slze_of; 
end  fillers; 
end  object; 


In  addition  to  typed  and  inherited  relationships  of  the  kind  described  above,  categories  and 
objects  can  be  equipped  with  non-inherited  attributes  which  are  used  to  further  characterize 
them.  RLF  attributes  are  used  to  annotate  categories  and  objects  with  static  information 
that  provides  additional  data  about  them.  These  attributes  are  often  used  in  combination 
with  RLF  actions  which  process  the  attributes  and  present  them  to  the  user.  In  particular, 
attributes  are  the  means  by  which  actual  file  contents  are  attached  to  reusable  assets  which 
are  modeled  as  objects  in  an  RLF  model.  SLIDE  18  illustrates  some  features  of  attributes. 
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Attributes 

•  can  be  integers,  strings  of  characters,  or  files 

•  have  names  so  they  can  be  referenced  and  used  by 
RLF  actions 

•  file  attributes  can  be  viewed,  extracted,  or  otherwise 
manipulated 

•  attributes  are  not  inherited  -  they  must  defined  at 
each  category  or  object  where  they  are  useful 
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The  RLF  currently  supports  string,  integer  or  file  attributes.  The  next  slide  includes  some 
simple  LMDL  attribute  declarations. 


Slide  19 


- ^ 

Lmdl  Attributes 

category  Extract  (  Action  )  is 
attributes 

string  Is  ‘Extract  Asset"; 
end  attributes; 
end  category; 

category  Quicksort  (  "Exchange  Sorts"  )  Is 
attributes 

file  desc_source  Is 

" sort_and_aearch/exchanga_sort_desc " ; 
end  attributes; 
end  category; 

object  "Exanple  Quicksort"  (  Quicksort  )  Is 
attributes 

file  desc.source  is 

■ sort_and_8earch/exchange_sort_desc " ; 
file  source  Is 

" 8ort_and_search/qulck_8ort_ . a ■ ; 
string  slze.of  Is  "24"; 
end  attributes; 
end  object; 

_ 


Actions  let  the  user  process  categories  and  objects  and  permit  access  to  system  and  library 
resources  within  a  context  appropriate  to  specific  categories  and  objects.  The  context  for 
these  actions  is  provided  by  RLF  attributes.  Actions  are  summarized  in  SLIDE  20. 
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Actions 

•  provide  library  users  with  appropriate  system  aruj  library  services 

•  basis  for  asset  viewing  and  extraction 

•  defined  within  model  definition  language  -  sample  Action  sub-model 
provided  in  RLF  distribution 

•  implemented  as  system  calls,  or  internal  Ada  procedures 

Slide  20 

•  inherited  like  reiationships 

«  have  names,  an  action  category,  a  list  of  action  targets,  and  a  list  of 
action  agents 

•  targets  reference  attributes  which  provide  input  for  the  action 

•  agents  reference  attributes  which  can  affect  how  the  action  is  performed 

•  can  be  privileged  which  means  they  are  unavailable  through  the  RLF  GB 
(restricted  to  administrative  use) 

•  can  be  restricted  at  subcategories  or  lower  level  objects 

The  RLF  administrator  should  become  familiar  with  the  basic  action  model  hierarchy  that 
is  included  with  the  sample  RLF  libraries  included  in  the  RLF  v4.1  release.  A  LMDL 
specification  for  a  subset  of  this  model  is  shown  on  the  next  slide.  Modifying  this  model  to 
add,  delete  or  modify  actions  is  covered  later  in  this  tutorial. 
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Action  Model  Subset  I 


Slid*  21 


a«t«0ory  ‘Aetlen  Daflnltlon"  (thing)  !• 

•nd  oatagotyi 

aatagoxy  'Aotlon  Typa"  CJUitton  Daf tnltion' )  la 
and  catagoxy/ 

oatagoxy  "Syataa  String*  ('Jkhtion  Typa")  ia 
and  oatagoxy; 

oatagoxy  "hda  rxooadoxa*  (“Sotion  Typa*)  la 
and  oatagoxy; 

oatagoxy  “Haaaaga  Sasa*  < "Action  Typa*)  la 
and  oatagoxy; 

oatagoxy  Action  ("Aetlon  Daf initlon* >  la 
xalatlonablpa 

has_aotioiL.typa  (1  ..  1)  of  ■‘Aotion  Typo"; 
and  ralationahlpa; 
and  oatagoxy; 

oatagoxy  Viaw  (Aotion)  ia 
xaatxiotad  xalationahipa 

baa_aotlon_typa  of  ‘Syataa  Stxina*; 
and  xaatxiotad; 
attxibutaa 

String  la  *xtaxa  -a  $lU.2_PA(nR  •»  A>; 
and  attrlbutas; 
and  oatagoxy; 


Library  actions  are  connected  to  the  content  of  a  library  model  through  LMDL  action  and 
attribute  specifications  at  the  appropriate  model  catagories  and  objects.  A  model  fragment 
showing  some  of  these  specifications  is  shown  on  SLIDE  22. 
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f  Local  Action  Specs 


SHd«22 


o«t*gory  '*Ziw«rtlo&  Sorts**  <  **Iikt«nkol  Sorts**  )  Is 
ottrifautos 

fils  doso.souroo  Is  **sort_sn4-sosrch/insortlon_sort_dssc**; 
•nd  ottrlbutosf 

SCtlOM 

**ltssd  Dosoriptlon**  Is  "Olsplsy  Doscrlptlon**  on  dosc.soureo; 
•ad  •otloas} 

•ad  oatagoryi 

objaet  '*lxsapX^  Quicksort**  (  Quicksort  )  Is 
•ttrlbutos 

£!!•  dosc.sourco  is  *‘*^**_^**^_«««*‘">*^^^*****»^^_**^"‘»_**^**** r 
fils  sourco  Is  '*sort_sBd_sosreb/qulok_sort_.s**; 
strlaa  slso_o£  Is  **34**; 

•ad  sttrlfautas} 

•ctioas 

"View  Cods  Sisa**  Is  "OlspXsy  latagsr**  oa  slM.ofi 
"Vioir  Souros**  is  Visw  oa  sourooi 
"■xtrsot  Souxoo**  is  Bxtraot/ 

•ad  Aotloas; 

•ad  objaetf 

V 


Finally,  RLF  models  can  make  use  of  a  special,  built-in  action  called  inferencing.  This 
capability  has  been  used  primarily  to  direct  a  user  browsing  an  RLF  model  and  to  provide 
that  user  with  advice  about  the  model  in  a  context-dependent,  goal-oriented  fashion.  The 
user’s  responses  to  inferencing-induced  questions  lead  the  user  to  categories  and  objects 
within  the  model  that  are  expected  to  meet  user  needs  as  these  are  elicited  during  the 
inferencing  process.  SLIDE  23  describes  some  inferencing  features. 

— 

Library  Inferencers 

•  defined  in  special-purpose  RLF  language 

•  attached  only  to  modeler-specified  categories  or  objects 

Slide  23  *  questions  about  the  user's  needs  and  intentions 

•  based  on  responses,  make  deductions  about  model  locations 
and  contents  that  are  of  interest  to  the  user 

•  can  focus  user  to  specific  category  or  object 

•  are  distributed  over  a  model  and  can  invoke  and  exchange 
information  with  each  other 

V _  ^ 


SLIDE  24  gives  a  LMDL  example  showing  how  inferencers  which  are  declared  in  separate 
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Rule  Base  Description  Language  (RBDL)  specifications  are  attached  to  network  nodes  and 
are  thus  made  accessible  to  the  library  end-user. 


Slide  24 
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Attaching  RBDL  Inferencer 

category  Quicksort  (  ■Exchange  Sorts*  )  Is 
restricted  relationships 

haB_bast_casa_o£  (1  ..  1)  of  Logarithmic; 
haB_avg_case_of  Cl  ••  1)  of  Logarithmic; 
has_worst_case_of  (1  ..  1)  of  Quadratic; 
end  restricted; 
attributes 

file  desc_source  Is  ■sort_and_search/exchange_sort_desc* ; 
end  attributes; 
end  category; 

attach  Inferencer  quicksort  to  Quicksort; 


4  Library  Management 

An  outline  of  the  topics  presented  in  this  section  is  given  in  SLIDE  25.  Examples  in  this 
section  assume  that  the  RLF-LIBRARIES  environment  variable  has  been  set  to  the  directory 
containing  the  reuse  library  being  modified  and  that  the  LMDL  translator,  Lmdl,  appears  in 
the  library  administrator’s  path. 
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Management  Topics 

•  convert  v3.0  libraries 

•  build  new  libraries 

•  remove  libraries 

•  modify  library  elements  -  change 

-  assets 

-  actions 

-  advice 


LMDL  is  significantly  different  from  its  specification  language  predecessors.  RLF  versions 
prior  to  v4.0  included  the  Semantic  Network  Description  Language  (SNDL)  which  has 
now  been  superceded  by  LMDL.  Since  LMDL  is  not  an  upwards  compatible  extension  of 
SNDL,  a  translator  tool  is  provided  to  convert  old  network  specifications.  This  tool  is  called 
Sndl-toJjndl.  Its  features  are  summarized  on  the  next  slide. 
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Translator  Features 

•  Syntax: 

Sndl_to_Ijmdl  [-help]  [<f ilename>]  [-pc] 
[-Indent  <num>]  [-o  <name>]  [-1  <naine>] 

•  Command  line  arguments: 

-help  -  get  list  of  command  line  arguments 
<f  lleneuiie>  -  name  of  file  to  translate 
-pc  -  preserve  ease  of  model  element  names 

-  indent  <num>  -  indent  ma|or  model  constructs  by  <num> 
spaces  (default  !s  3) 

-o  <naiiie>  -  write  output  to  named  file;  default  is  standard  out 
-1  <xiame>  -  write  execution  log  to  named  file 


The  LMDL  language  processor  provides  the  baisic  mechanism  for  creating  and  maintaining 
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For  incremental  processing  of  entire  model  segments,  it  is  often  convenient  to  package  the 
segments  separately  and  to  use  the  incremental  specification  feature  of  LMDL  to  refer  to 
the  bcisic  parent  model.  The  syntax  and  an  example  of  incremental  network  specification  is 
given  on  the  next  two  slides. 
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Top  Level  LMDL  Syntax 

library jnodal^pac  :;s 

library  modal  moda/jiama  la 
[IncramantalJndlcation] 

[rooljcatagory] 

{catagoryjorjobjact  jar  Jnfarancar  } 
and  modal  jMma ; 

Incremental  LMDL  Clause 

lncremental_lndlcatlo&  = 

'extend'  'library'  'model'  inodel_.naine 


In  addition  to  this  syntax,  which  specifies  the  name  of  the  pre-existing  library  which  will 
be  extended,  incremental  LMDL  specifications  can  not  make  root  category  definitions  other 
than  to  add  new  definitions  to  the  root  category  definition  of  the  library  being  extended. 
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Incremental  LMDL  Example 

library  model  'Sort,  Search,  and  Nath  Algoritbma*  is 
extend  library  model  *Sort  and  Search  Algorithms*; 

—  additional  category  and  object  definitions 

--  and  Inferencers  attachments  describing  math  functions 

—  connected  to  categories  and  objects  in  the 

—  sort  and  search  algorithms  library  model 

end  ‘Sort,  Search,  and  Math  Algorltluns* ; 


Translating  this  specification  would  create  a  new  library  named  "Sort,  Search,  and  Math 
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Algorithms"  containing  all  the  constructs  of  the  sort  and  search  algorithms  library  plus  any 
additional  entities  describing  math  function  algorithms. 

The  rest  of  the  slides  in  this  section  address  the  modification  of  model  elements  which  are 
usually  the  responsibility  of  the  library  manager.  These  model  elements  include  assets  (model 
objects  with  “filled”  relationships  and  attribute  values),  actions  and  inferencers. 

SLIDE  30  discusses  some  typical  asset  change  possibilities  and  the  following  two  slides  show 
a  category  definition  and  various  object  definitions  which  define  the  asset.  An  object  decla¬ 
ration  typically  includes  an  attribute  which  locates  the  file  containing  the  asset  contents. 
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Modifying  Assets 

•  Add  assets  by  inserting  or  modifying  LMDL  object  declarations 

•  Corresponding  LMDL  category  must  already  be  defined 

•  Assets  are  deleted  by  changing  LMDL  object  spec  and  Re-Lmdl-ing  the 
entire  spec 

•  Library  Jianager  can  also  delete  assets  by  deleting  object  attributes 

But,  machine  readable  network  no  longer  in  sync  with  LMDL  spec 

•  Contents  can  be  changed  by  copying  a  new  file  to  the  location  stored  as 
part  of  object  attribute  definition 

But,  old  asset  version  is  no  longer  available  to  library  user 
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Category  Declaration 

category  Quicksort  (  ‘Exchange  Sorts*  )  Is 
restricted  relationships 

has_best_case_o£  (1  ..  1)  of  Logarithmic; 
has_avg_case_o£  (1  ..  1)  of  Logarithmic; 
haa_worst_case_of  (1  ..  1)  of  Quadratic; 
end  restricted; 
attributes 

file  desc_source  Is 

■ sort_and_search/exchangs_sort_desc ■ ; 
end  attributes; 

end  category; 

Simple  Object  Declaration 

object  ‘Example  Quicksort*  (  Quicksort  )  Is 
attributes 

file  source  Is 

*  sort_and_search/(iulck_sort_ .  a  * ; 
end  attributes; 

end  object; 


Note  that  the  path  location  for  the  source  attribute  is  given  relative  to  the 
$RLF-LIBRARIES/Text  path. 
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Full  Object  Declaration 

objact  “KxaiBpla  Qulckaort*  (  Quicksort  )  la 
rastrlctad  ralatlonshlps 

ls_wrlttan_ln  (1  ..  1)  of  *Sourca  Languaga*; 
works_oa  (1  ..  1)  o£  ‘Data  Struccura*; 
haa_«orst_casa_o£  (1  ..  1)  o£  Quadratic; 
haa_alsa_o£  (0  ..  1)  o£  Muabar; 
and  raatrlctad; 
flllara 

Ada  aatls£las  ls_wrlttan_ln; 

Array  satla£las  worka_on; 

satla£laa  tiaa_worat_caaa_o£ ; 

*Twanty-Four*  satls£las  haa_slza_o£; 
and  flllara; 
attrlbutaa 

£lla  dasc_soarca  la 

*  aort_and_aaarch/azchanga_aort_daac  * ; 

£lla  aourea  la  *aort_and_saarcb/gulck_sort_.a*; 
string  slsa_o£  la  *34*; 
and  attrlbutaa; 
actions 

■Vlaw  Coda  slsa*  la  'Display  Intagar*  on  alsa_o£; 

*Vlaw  Sourca*  la  Vlaw  on  aourea; 

'Ixtract  Sourca*  la  Kxtract; 
and  actions; 

and  objaet; 


I 

I 


Action  management  involves  maintaining  and  enhancing  the  library’s  built-in  action  model 
and  allocating  action  and  attribute  declarations  for  categories  and  objects  declared  for  the 
library.  While  the  Library Jianager  provides  a  limited  form  of  action  editing,  library  man¬ 
agers  will  likely  want  to  perform  most  of  their  management  functions  directly  on  the  LMDL 
specification  file(s)  for  the  library. 

SLIDE  33  presents  some  action  management  concepts.  A  portion  of  the  provided  RLF 
example  action  model  is  included  on  SLIDE  21. 
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f  Modifying  Actions 
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Slide  33 


•  New  actions  are  added  within  the  library  action  submodel 

•  System  String  actions  invoke  system  services  -  action  attributes 
specify  actual  string  with  parameters 

•  Ada  Procedure  actions  are  internal  -  the  RLF  must  be  modified  to  add 
more 


•  Built-in  internal  actions  are  import,  Export,  Extract, 

Display  attributes 

•  Actions  can  be  deleted  and  modified  within  the  library  models  LMOL  spec 

•  Actions  can  be  deleted  within  the  Library  Jtanager 

But,  model  spec  should  be  changed  appropriately 


Note  that  if  actions  are  removed  from  the  action  submodel,  references  to  these  actions  must 
be  removed  wherever  they  appear  in  the  model.  Local  action  declarations  can  be  removed 
to  make  the  action  unavailable  to  particular  categories  or  objects. 

The  next  few  slides  show  some  examples  of  action  modification  and  explore  some  additional 
action  capabilities  (such  as  action  agents).  These  capabilities  are  treated  more  fully  in  the 
RLF  Modeler’s  and  Administrator’s  Manuals. 
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New  Action  Definition 


Slide  34 


category  Print  (  Action  )  Is 

—  this  action  category  describes  a  general  print  action 
restricted  relationships 

hns_actlon_type  (1  ..  1)  of  ‘System  String"; 
end  restricted; 
attributes 

--  it  marks  the  file  to  be  printed 
--  marks  the  UNIX  print  conmand  to  use 
--  %k2  marks  any  options  to  the  print  conmand 

—  also  run  the  action  In  the  UNIX  background 

—  so  the  RLF  application  continues 
string  prlnt_coBmand  Is  ‘Vtl  X>(2.  i#  &■; 

end  attributes; 
end  category; 


V 


SLIDE  34  defines  a  new  system  action  to  be  used  to  print  other  asset  contents.  The  strings 
*/,'/, 1  and  y,y.2  are  placeholders  for  action  agents  that  provide  qualifiers  to  the  system  command 
that  ultimately  implements  the  action.  Values  for  these  placeholders  (and  for  the  action 
target(s)  identified  by  #i)  are  obtained  locally  at  the  invoking  category  or  object. 

The  next  slide  show  two  simple  action  references  for  the  Print  action.  The  following  slide 
shows  a  more  complex  reference. 


Page  26 


February  1993 


STARS-lIC-05156/019/00 


- 

Partial  Action  Reference 

object  'Exanple  Quicksort*  (  Quicksort  )  Is 
actions 

’Print  Source*  Is  Print  on  source 

with  prlnt_coDnand,  prlnt_optlons; 
end  actions; 
end  object; 

Complete  Action  Reference 

object  ’Bxanple  Quicksort*  (  Quicksort  )  Is 
attributes 

file  source  Is  *sort_and_search/<iulck_sort_.a*; 

string  prlnt_coiii&and  Is  *lpr*; 

string  prlnt_opt Ions  Is  *-Pprlnterl* ; 
end  attributes; 
actions 

"Print  Source*  Is  Print  on  source 

with  prlnt_coiBnand,  prlnt_optlons; 
end  actions; 
end  object; 


In  the  first  example,  since  there  are  no  object  attributes  to  provide  values  for  the  action  target 
and  agents,  the  RLF  action  mechanism  will  look  first  in  the  Quicksort  category  declaration 
for  corresponding  attributes  to  provide  values,  and  then  if  necessary  in  Quicksort  ancestor 
categories.  The  second  example  provides  object  values  for  the  action  targets  and  agents. 
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Complex  Action  Reference 

Ob j act  ■Bxanpl*  Quickaort*  (  Quickaort  )  la 
attrlbutoa 

flla  abatract  la  '■aort_and^aaarcb/qulck_aort_abatract*  i 
£lla  parCoraanca_atudy  la  *aort_and_aaarcb/qulck_aort_par£* j 
tlla  aourca  la  ■aort_asd_aaarcb/(iulck_aort_.a* ; 
atrlng  prlnt_coninand  la  'Ipr*; 
atrlng  prlnt_optlona  la  "-Pprlntarl*; 
and  attrlbutaa; 
act Iona 

■Print  All  Data*  la  Print  on 

abatract,  parfonBanca_atudy,  aourca 
with  print _coBnand,  prlnt_optlona; 

■Print  Sourca*  la  Print  on 

aourca  with  prlnt_conBand,  prlnt_optlona; 
and  actlona; 
and  objact; 


This  would  provide  a  "Print  Source"  action  to  just  print  the  implementation’s  source  and 
a  "Print  All  Data"  action  which  would  print  the  implementation’s  abstract,  performance 
study,  and  source.  When  the  "Print  All  Data"  action  is  invoked,  it  will  iterate  over  the  list 
of  targets  performing  the  action  described  by  action  category  Print  for  each  file  in  the  list. 

Actions  are  modified  by  editing  the  library’s  specification  file  and  modifying  the  action  sub¬ 
model  and/or  by  changing  the  action  declarations  at  particular  categories  or  objects.  For 
example,  the  action  sub-model’s  View  action  can  be  changed  to  one  of  the  variants  shown  on 
the  next  slide  -  see  SLIDE  21  for  the  original  definition  for  this  action. 
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Slide  37 


Alternate  View  Action 

category  View  (  Action  )  is 
restricted  relationships 

has_aotlon_type  o£  "System  String"; 
end  restricted; 
attributes 

string  is  "xterm  -e  /usr/ucb/vlew  ##"; 
end  attributes; 
end  category; 


Another  View  Action 

category  View  (  Action  )  is 
restricted  relationships 

has_actlon_type  of  "System  String"; 
end  restricted; 
attributes 

string  is  "asset_vlew.cah  ##  ft"; 
end  attributes; 
end  category; 


For  the  second  example,  when  the  library  model  had  been  retranslated  using  the  LMDL 
translator,  Lmdl,  the  view  action,  when  invoked,  would  execute  the  csh  shell  script  named 
asset-view.csh  passing  the  name  of  the  file  to  the  script  as  a  parameter.  This  script  would 
also  execute  in  the  UNIX  background  allowing  the  RLF  application  to  continue. 

Note:  To  save  time  when  modifying  a  library  model’s  action  categories,  if  the  only  changes 
made  were  changes  to  the  string  attributes  at  action  categories,  the  Lmdl  translator  should 
be  invoked  with  the  -state  command  line  option  when  retranslating. 

The  last  kind  of  model  element  that  the  library  administrator  may  need  to  maintain  are 
inferencers.  The  definition  and  placement  of  inferencers  for  use  within  a  complex  network 
model  is  normally  handled  by  the  model  developer.  The  administrator  may  be  called  upon 
to  relocate  inferencers,  replace  them  with  new  versions,  or  to  delete  them  entirely.  Again, 
although  deletion  of  an  inferencer  can  be  done  within  the  LibraryJlanager  application,  it 
is  usually  easy  to  make  changes  to  the  LMDL  spec  directly.  Executing  Lmdl  -state  will 
quickly  modify  the  internal  network  when  only  inferencers  (and  attributes)  have  changed 
but  the  specialization  and  aggregation  hierarchies  remain  stable. 

The  next  slide  shows  a  specification  fragment  with  and  without  an  attached  inferencer. 
Inferencer  definition  is  accomplished  by  executing  Rbdl.  Note  that  if  no  changes  to  inferencer 
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placement  or  naming  occur,  inferencer  updates  can  be  accomplished  independently  of  LMDL, 
Rbdl  and  AdaTAU  are  discussed  fully  in  the  RLF  Modeler's  Manual. 


SIktoas 


/  > 

Category  With  Inferencer 

category  Quicksort  (  ‘Exchange  Sorts*  )  is 
restricted  relationships 

haa_best_case_o£  (1  ..  1)  of  Logarithmic; 
has_avg_case_of  (1  ..  1)  of  Logarithmic; 
has_worst_case_of  (1  ..  1)  of  Quadratic; 
and  restricted; 
attributes 

file  de8c_source  is 

*  sort_and_searcb/exchange_  sor  t_deac •  ; 
end  attributes; 
end  category; 

attach  inferencer  quicksort  to  Quicksort; 

Category  Without  Inferencer 

category  Quicksort  (  ‘Exchange  Sorts*  )  is 
restricted  relationships 

end  restricted; 
attributes 

end  attributes; 
end  category; 


When  only  a  portion  of  the  model  defining  library  advice  has  been  removed,  it  will  be 
sufficient  and  quicker  to  retranslate  the  specification  using  the  LMDL  translator’s  -state 
command  line  option. 


5  Library  Maintenance 

An  outline  of  the  topics  presented  in  this  section  is  given  in  SLIDE  39.  The  library  adminis¬ 
trator  is  responsible  for  maintaining  the  performance  and  day-to-day  operations  of  an  RLF 
reuse  library.  The  administrator  is  also  responsible  for  improvements  to  the  library  whether 
they  come  from  user  feedback  or  the  library  modeler  or  other  sources. 
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Maintenance  Topics 

•  managing  assets 

•  collecting  metrics 

•  coordinating  user  feedback 

•  optimizing  performance 

•  maintaining  RLF  software 


The  first  item  on  the  list  is  essentially  covered  in  the  previous  section.  The  library  adminis¬ 
trator  should  maintain  some  sort  of  configuration  management  on  the  library’s  assets  so  that 
old  versions  can  be  recovered,  and  differences  between  old  and  new  versions  can  be  revealed. 
The  extent  of  this  activity  and  its  visibility  to  the  user  and  the  reuse  library  is  up  to  the 
library  administrator  and  may  be  affected  by  the  nature  of  the  assets  in  the  library. 


The  RLF  does  not  come  pre-configured  to  support  the  collection  and  reporting  of  usage 
metrics.  However,  the  RLF  action  mechanism  can  be  applied  to  collect  and  report  library 
metrics.  Some  ideas  in  this  direction  are  suggested  on  the  next  slide. 


Slide  40 


Metrics  Ideas 

•  Modify  Extract  action  to  count  asset  retrievals 

•  Modify  Extract  action  to  add  user  to  list  of  asset  customers 

•  Convert  View  action  to  a  shell  script  that  counts  number  of 
viewer  executions 

record  user  name  of  library  user  executing  the  action 

•  Modify  RLF  start-up  scripts  to  record  user  info  and  RLF  usage 
length 

•  Provide  top-level  action  to  report  library  statistics  to 
administrators  and  perhaps  users 

_ 
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The  RLF  can  automate  user  feedback  through  its  action  mechanism.  Tlie  library  modeler 
or  administrator  could  include  an  action  which  would  appear  at  every  category  or  object 
which  would  mail  the  library  administrator  a  message  which  the  user  could  enter  while  still 
running  the  Graphical-Browser  and  the  question,  problem,  or  suggestion  is  still  fresh.  Help 
actions  could  also  be  modeled  this  way.  The  action  could  mail  the  administrator  the  Hie 
created  as  the  result  of  spawning  a  text  editor  from  the  Graphical-Browser. 

The  perceived  performance  of  the  RLF  software  can  be  affected  by  many  factors.  The  RLF 
implementation  team  is  constantly  working  to  address  raw  performance  issues.  The  next 
slide  provides  some  additional  factors  to  consider.  Some  of  these  factors  must  be  addressed 
by  those  responsible  for  the  library  model. 


Slide  41 


^ - 

Performance  Factors 

•  Is  the  model  overly  complex? 

•  Has  sufficient  model  guidance  been  provided  (inferencers)? 

•  Are  user  workstations  properly  equipped  (memory  and  swap 
space)? 

•  Have  the  X  resources  for  the  OraphlcaUroweer  been 
properly  adjusted  (bitmaps  and  Browser  file  definitions)? 

•  Have  sufficient  user  profiles  been  developed  (startup  scripts  and 
.rlfrc  files)? 

•  Have  user  suggestions  been  solicited  and  honored  where  possible? 


An  outline  of  areas  to  consider  in  regard  to  the  maintenance  of  RLF  software  is  shown  on 
SLIDE  42. 
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Slide  42 


/ - \ 

Maintaining  RLF  Software 

•  getting  software 

•  doing  software  updates 

•  reporting  errors 

•  getting  help 


Most  aspects  of  software  installation  and  maintenance  are  covered  in  the  RLF  installation 
guides.  In  addition  there  are  mailing  lists  which  cover  the  RLF  from  different  perspectives. 
These  lists  are  outlined  on  the  next  slide.  The  RLF  itself  is  available  via  anonymous  FTP 
at  the  internet  address  stars.rosslyn.paramax.com  in  the  directory  /pub/RLF. 
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RLF  Mailing  Lists 

rlf@stars.ballston.paramax.coin 

Public  forum  for  discussing  RLF  issues 

rif*request@stars.ballston.paramax.com 

Address  for  submission  of  RLF  registration  forms  and  mailing 
list  maintenance  requests 

rlf-bugs@stars.ballst0n4Niramax.com 

Completed  Program  Problem  Reports  and  New  Feature 
Requests 


6  Library' Manager  Application 

The  Library-Manager  tool  performs  tasks  associated  with  library  administration.  These  in¬ 
clude  manipulating  entire  RLF  reuse  libraries  built  from  LMDL  library  model  specifications, 


Page  33 


Ff^bruar,'  1993 


STAKS-rC-Ool.'Hi/OHt/UO 


browsing  and  examining  the  contents  of  reuse  libraries,  and  performing  smaller  scale  manip¬ 
ulation  of  library  parts.  The  Library-Manager  only  supports  limited  library  model  editing 
including  the  deletion  of  attributes  and  inferencers  from  a  model.  Any  editing  of  this  sort 
done  with  the  Library-Manager  should  be  also  be  done  in  the  LMDL  specification  of  the  li¬ 
brary  model  in  order  to  maintain  integrity  between  the  specification  and  the  model,  although 
the  using  the  Library-Manager  allows  the  changes  to  be  made  without  rebuilding  the  entire 
model  at  that  time. 

The  slides  in  this  section  survey  the  use  and  features  of  the  Library-Manager  application. 
Before  executing  the  application,  the  user  should  select  which  RLF  library  location  to  process 
by  setting  a  value  in  the  .rlfrc  file,  setting  the  RLF_LIBRARIES  environment  variable,  or 
supplying  the  library  path  on  the  command  line  through  the  -I  option. 

At  startup,  the  Library-Manager’s  screen  appears  as  in  SLIDE  44.  Initially,  only  the  Library 
and  Quit  menu  items  are  active.  The  title  bar  also  lists  the  current  working  directory  and 
selected  libraiy. 


Slide  44 


The  user  selects  a  library  to  administer  using  the  Library  button.  The  next  slide  shows 
that  a  list  of  available  libraries  is  presented  to  the  user.  A  similar  list  of  libraries  appears  if 
the  user  has  not  yet  selected  a  library  and  wishes  to  delete  one  of  the  ones  available  in  the 
chosen  Instances  directory.  A  cancel  button  is  available  if  the  user  decides  not  to  proceed. 
The  Close  and  Save  menu  items  are  available  after  a  library  has  been  selected.  Save  makes 
permanent  the  library  changes  made  since  the  library  v/as  opened.  Close  closes  access  to 
the  library  but  does  not  save  changes. 
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I  List  of  Libraries  available  after  selecting  Load  I 


Slide  45 


ftwailable  Libraries 
Softwo'e  Technology 
Deno  llctions 
CoMMon  Data  Hodel 
(ISU  Taxonony 
Demo  Animals 


Cancel 


Similar  list  appears  after  selecting  Delete 


✓ 


After  a  library  has  been  loaded,  the  screen  appears  as  shown  on  the  next  slide.  The  remaining 
menu  bar  choices  are  now  active.  Data  about  the  top  level  concept  is  displayed  in  the  main 
window. 


r 
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Update  of  Library  and  Text  Info  After  Load 


B  Libra-yjtanagir 

”0l 

library  ^it  ftmt  Hanagaiwnt  Quit 

Oiractory  :  /(>xl2/'tchr«y/rlf/inst«ice«/'  Library  : 

Sort  and  Search  Rlgorithns 

Cirrant  catagory:  Thing 

Parent  categories; 

Child  categories:  Rlgorithm  Attribute  Values  Action  Oef  -tion 

Child  objects; 

■:  :  ,e  ,  ■ 

L_ 

v. 


The  available  menu  choices  change  depending  on  what  choices  the  user  has  maxle  while 
interacting  with  Library Jfanager.  For  example,  the  next  slide  shows  how  the  Delete  button 
is  no  longer  active  after  a  library  has  been  loaded. 
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Slide  47 


Changes  in  sensitivity  in  Library  Pulldown 
after  loading  a  library.  Delete  is  not  allowed 
on  an  open  library. 


El  Llbrary-Hanager 

@11 

^ouse  Edit  teset  Haiagaent  Quit 

^Uoad  |y  .  /pxl2>'llz/dev/lnst«nces/llbraries/  Library 

:  Deno  Actions 

category:  itea 
itagories: 

jtegories:  Action  Definition  Sounds  Inages  Building 
Save  tiects: 


There  are  two  main  choices  in  the  Browse  menu:  Navigate  Hierarchy  and  Examine  Hi¬ 
erarchy.  The  collection  of  navigation  choices  are  shown  on  the  next  slide.  By  selecting  from 
this  submenu,  the  user  can  textually  navigate  the  library.  Most  of  these  are  self-explanatory. 
The  Backtrack  Relationship  choice  produces  a  submenu  of  all  the  relationships  which 
have  the  current  category  as  a  filler  type.  The  owner  of  each  relationship  is  also  shown. 
Choosing  one  will  make  the  relationship’s  owner  category  the  current  category.  Tlie  Go  to 
Action  Category  choice  produces  a  submenu  of  all  the  action  categories  associated  with 
the  actions  at  the  current  category.  Choosing  one  will  make  it  the  current  category.  The 
Library-Manager  is  the  only  RLF  tool  that  permits  a  user  to  browse  an  action  submodel. 

Navigate  Hierarchy  Pulldown  Menu  ^ 


Ubrsry 

Brxwee  |  Edit  ftnet  Hanagenent  Quit 

Directory 

iNavigate  Hiqigirchy  ^ 

User  Entered  Name 

d  Search  Algorithms 

Current  c 
Parent  ca 
Child  cat< 
Child  obji 

I 

Exanine  Hierarchy  ft 
tegories: 

igories:  Algorithms  ( 
sets: 

Go  to  Parent  ► 

Go  to  Child  h 

Follow  Relationship  P 
Backtrack  Relationship  h 

Go  to  Action  Category  » 

‘inltion 
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The  next  slide  shows  the  submenu  choices  for  the  Examine  Hierarchy  menu.  These  choices 
do  what  they  say;  if  there  are  no  actions,  attributes  or  inferencers  available  at  the  current 
node,  the  submenu  is  greyed  out. 


- 

Examine  Hierarchy  submenu.  Offers  to  display 
those  items  which  exist  at  this  node  -  note 
that  Display  Relationships  is  always  given 
as  a  choice. 


Slide  49 


SI  Libraru 

Ubrary 

Browse  |  Edit  Asset  Hanageeent  Quit  | 

Directory 

Navigate  Hierarchy  b 

t  and  Search  Algorithns 

Parent  ca 

Exanlne  Hierarchy 

Display  Aslationships 
Display  Actions 

Display  Attributes 

1 

Definition  ■ 

Child  catagoriu:  Algorithns  f 
Child  objects: 

Curent  object:  Heap  Ada 

Parent  categories:  Heapsart 

Has  attributes. 

Has  actions. 

1""  —  ~ 

✓ 


The  current  version  of  the  LibraryJfanager  provides  two  deletion  options  for  node  attributes 
and  inferencers.  A  submenu  of  available  attributes  for  the  current  node  is  shown  on  the  next 
slide.  If  the  user  selects  an  available  attribute  or  inferencer  to  delete,  the  item  is  deleted 
once  the  library  has  been  saved  with  changes.  There  is  no  immediate  confirmation  that 
the  deletion  has  been  accomplished.  Such  deletions  should  be  treated  with  caution  as  the 
corresponding  LMDL  spec  for  the  library  model  has  not  been  changed. 
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Slide  50 


Delete  Attribute  submenu  under  Edit.  This 
node  has  these  attributes  so  they  are  shown. 

No  inferencers  are  available  at  this  node  but 
that  submenu  would  contain  them  if  there  were. 

13  Libra-a-Hanagy  a 

Ubrary  Browsa  Edi^  Assat  NanageMnt  Quit 

Diractom  :  /pxl2/  Balata  Attributa  4  daac.sourca  <taxt>  Saarth  Algorithns 
Parant  InfarancT^  scurca  <t«t) 

Child  catagorias:  Algarithas  Attribut  siie.af  (text)  nition 
Child  objects:  *  ■'  ~  ■  * 


Dsrant  objact:  Exaapla  Shakar  Sort 
Parent  categories:  Shakersort 
Has  attributes. 

Has  actions. 


The  current  version  of  the  Library-Manager  is  an  initial  version.  Substantial  improvements 
are  planned  for  the  near  future.  Currently,  the  Asset  Management  functions  are  lim¬ 
ited  to  asset  extraction  to  the  user’s  working  directory.  Export  and  Import  are  not  yet 
implemented  -  they  are  intended  to  support  asset  exchange  between  libraries. 


Asset  Management  Sub  Menu. 

3  Librargjlanagsr 
Ubrarg  frtwss  Edit 

Directory  :  /pxl2/sc»rey/  Extract  Assetj  Liliraru  :  Sort  and  Search  Alooritii 
_ _ .  Export Asset  I  I  B 
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Parent  categories:  cxpwt  nssei 

Child  categories;  Algarc  [i^art  Asset  Values  Action  Definition 
Child  objects: 


Cirrent  object:  Exanple  Shaker  Sort 
Parent  categories:  Shakarsort 
Has  attributes. 

Has  actions. 
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7  RLF  Preferences  File 

RLF  users  and,  in  particular,  RLF  Administrators  can  personalize  their  interaction  with  the 
family  of  RLF  applications  by  the  installation  and  use  of  the  .rlfrc  preferences  file.  For 
example,  SLIDE  52  summarizes  some  of  tl  e  options  which  can  be  set  with  this  file. 


In  general,  following  UNIX  conventions,  conflicting  values  established  on  an  RLF  command 
line  override  those  set  earlier,  either  as  environment  variables  or  as  .rlfrc  values,  while 
any  surviving  environment  variables  override  any  values  set  in  the  .rlfrc  file.  Thus,  if  the 
RLF -LIBRARIES  environment  variable  is  set,  it  will  override  any  library  directory  entry  in 
the  .rlfrc  file. 

A  default  library  setting  will  cause  the  browser  to  open  that  library  immediately.  Within  a 
library,  a  specific  node  can  be  chosen  as  the  first  focal  point  of  the  browser.  View  control 
can  be  used  to  select  whether  the  topology  view  is  on  or  off  at  start-up,  and  whether  the 
first  graphical  view  drawn  is  a  specialization  view  or  relationship  view.  The  depth  of  the 
view  can  also  be  set. 

If  a  user  does  not  specify  any  advice  options,  the  user  must  answer  some  start-up  questions  to 
select  preferences  during  the  first  inferencing  session.  If  a  user  wishes  to  establish  alternate 
bitmaps  for  model  icons,  these  can  be  set-up  through  the  .rlfrc  as  well.  The  user  can  also 
select  some  options  to  be  observed  when  running  the  RLF  language  translators  Lmdl  and 
Rbdl. 

The  complete  syntax  for  the  .rlfrc  file  is  given  in  the  Administrator’s  manual.  A  sample 
specification  file  is  shown  on  the  next  multi-part  slide. 
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Example  .rifrc  File 

—  I  atartup  fila  tor  tho  Kauao  lUbraxy  Fra 


»rk  v«r*lon  4 . 1 


_ I  ubrary  dlraotory  or  tunaa  apaoltlcatlona 


— library  41raetory  i  /path/litbrarlaa 
—library  i  "Sort  and  Saaroh  jaaorltlaM" 


atara  ter  tba  RLF  Oraphloal  Browaar 


topology  I  ott 

oardlnallty  >  ott 

layout  ottaat  i  x  i  30 

layout  ottaat  i  y  i  S 

hlatory  laagth  i  50 

vlaw  typa  i  apaolallsatlon 

vlaa  daptb  i  ralatlonalilp  t  3 


--I  BdaTau  lataraaolng  aattlaga 


